Refactor documentation #2079
Refactor documentation #2079
Conversation
k8s-ci-robot
added
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rexagod The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
approved
Refactor documentation for the release workflow and update the PR template.
rexagod
force-pushed
the
release-process-updates
branch
from
515c347
to
b3ac935
Compare
|
|
||
| **How does this change affect the cardinality of KSM**: *(increases, decreases or does not change cardinality)* | ||
| **How does this change affect the cardinality of KSM**: <!-- Does this PR increase, decrease or does not affect KSM's overall cardinality? --> |
There was a problem hiding this comment.
| **How does this change affect the cardinality of KSM**: <!-- Does this PR increase, decrease or does not affect KSM's overall cardinality? --> | |
| **How does this change affect the cardinality of KSM**: <!-- Does this PR increase or decrease the number of metrics or the number labels within specific metrics created? --> |
Good idea, I would suggest to explain what cardinality means for folks who are not super familiar.
| Fixes # | ||
| **Which issue(s) this PR fixes**: <!-- Optional, should be in `Fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the mentioned issue(s) when PR gets merged --> | ||
|
|
||
| **Choose one below, based on the nature of this PR:** |
There was a problem hiding this comment.
Do we want to provide an explanation so it's easier to pick for the contributor?
|
|
||
| ## Prepare your release | ||
| Note: For a stable release, first a release candidate (e.g. `v1.2.0-rc.0`) should be cut. If, after a period of |
There was a problem hiding this comment.
| Note: For a stable release, first a release candidate (e.g. `v1.2.0-rc.0`) should be cut. If, after a period of | |
| Note: For a breaking major release, first a release candidate (e.g. `v3.0.0-rc.0`) should be cut. For minor or patch releases, this is not necessary. If, after a period of |
|
|
||
| ## Prepare your release | ||
| Note: For a stable release, first a release candidate (e.g. `v1.2.0-rc.0`) should be cut. If, after a period of | ||
| **7 days**, no bugs or issues were reported after publishing the release candidate, a stable release (e.g. `v1.2.0`) |
There was a problem hiding this comment.
| **7 days**, no bugs or issues were reported after publishing the release candidate, a stable release (e.g. `v1.2.0`) | |
| **7 days**, no bugs or issues were reported after publishing the release candidate, a stable release (e.g. `v3.0.0`) |
| * Only include user relevant changes | ||
| ### Workflow | ||
|
|
||
| * Bump the version in [`VERSION.md`](VERSION.md). |
There was a problem hiding this comment.
| * Bump the version in [`VERSION.md`](VERSION.md). | |
| * Bump the version in [VERSION](VERSION). |
This is not a markdown file but a plain text file.
| * Changelog entry | ||
| * Only include user relevant changes | ||
| ### Workflow | ||
|
|
There was a problem hiding this comment.
Add a couple of steps before, as I believe this order makes more sense:
* If this is a new major or minor release, create a release branch from `main` e.g. `release-2.10`
* Push the release branch to `kubernetes/kube-state-metrics`
* Create a branch `prep-release-v2.10`.
|
|
||
| * Bump the version in [`VERSION.md`](VERSION.md). | ||
| * Run `make examples`, which will re-generate all example manifests to use the newer version. | ||
| * Cut the new release branch, e.g. `release-1.2`, or merge/cherry-pick changes onto the minor release branch you intend |
There was a problem hiding this comment.
| * Cut the new release branch, e.g. `release-1.2`, or merge/cherry-pick changes onto the minor release branch you intend |
Handled before
| * Cut the new release branch, e.g. `release-1.2`, or merge/cherry-pick changes onto the minor release branch you intend | ||
| to tag the release on. | ||
| * Include the following changes in the release PR (cut from `main`). | ||
| * Update the [compatibility matrix](README.md#compatibility-matrix). |
There was a problem hiding this comment.
| * Update the [compatibility matrix](README.md#compatibility-matrix). | |
| * Update the [compatibility matrix](README.md#compatibility-matrix) and the link to the container image in [README.md](README.md) |
| First a release candidate (e.g. `v1.2.0-rc.0`) should be cut. If after a period of 7 days no bugs or issues were reported after publishing the release candidate, a stable release (e.g. `v1.2.0`) can be cut. | ||
| * To generate changelog, follow the process below: | ||
| * Fetch all commits since last release, for instance, when preparing for `v2.9.0`, do | ||
| `git log --oneline --decorate upstream/release-2.8..upstream/main`. |
There was a problem hiding this comment.
Isn't it easier to look at the closed PRs since the previous release?
| under their associated PRs, wherever possible. | ||
| * Format the message in the manner: `[<category>] <PR header> <PR number> <Author>`. | ||
| * All lines should be full sentences. | ||
| * Cut the new release-candidate tag, e.g. `v1.2.0-rc.0`. |
There was a problem hiding this comment.
Let's cut the release directly and release candidates only for breaking releases.
|
/triage accepted /close |
k8s-ci-robot
added
triage/accepted
|
@logicalhan: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
Adding a bit of context here, this was closed in favor of #2085, that aims to automate all manual release steps. |
What this PR does / why we need it: Refactor documentation for the release workflow and update the PR template.
How does this change affect the cardinality of KSM: No change.